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System and method for mana ging messaging services 
Field of the invention 

The present invention generally relates to messaging services and 
new possibilities to deploy a messaging service and after that to control,- 
adjust, and report the use of the messaging service. 



Background of the invention 

Messaging-based commercial services available today mainly use 

10 the short message service (SMS), the enhanced messaging service (EMS), 
and the multimedia messaging service (MMS) messages to reach users/ 
customers. Messaging markets have recently been changed so that the 
share of person-to-person messaging revenues will decrease and the share 
of other messaging revenues will increase. For example, messaging reve- 

1 5 nues related to entertainment and advertisement will probably increase in the 
next years. Uncontrolled service management requires the implementation of 
a number of various communication methods between the network operators 
and the service providers. A service provider may need to use different 
communication methods with different network operators. A communication 

20 method includes more than message routing and an application protocol, 
such as wireless application protocol (WAP). For example, the SMS centres 
of different network operators may require different protocols. Using a mes- 
sage router, such as the First Hop message router manufactured by the 
applicant, can solve the drawback of different communication methods. The 

25 message router provides so called messaging connectivity. 

FIG. 1 shows a controlled service management provided by a 
message router. There are three service providers, one service operator, two 
network operators, and a set of terminals. The message router 101 of the 
service operator transmits messages between the services and the network 
30 operators, such as a service 102 and a network operator 103. For example, 
the service 102 can communicate with the SMS centres of both the network 
operators via the message router. Thus, the service 102 does not need to 
know SMS center-specific details; it just needs to know one communication 
method, which it uses with the message router. 
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A message router implements the messaging connectivity, but the 
messaging connectivity solves only part of the drawbacks. 

FIG. 2 illustrates the use of a messaging service. The messaging 
service 201 receives a user message 202 sent by an end-user 203 and as 
5 response to the message received, the messaging service 201 sends a re- 
sponse message 204 to the user. The messaging service may include some 
means for processing messages, but it is uneconomical to implement and 
update the said means of a number of messaging services. 

The applicant's patent application FI20011813 concerns process- 
10 ing SMS messages. This 14 th of October 2001 filed application teaches that 
messages must be classified to make the handling of messages possible. 
The classification can be done by the user or by some administrator. The 
classification is defined with a special programming tool generated for this 
purpose. Known programming tools, like editors, and techniques can be used 
15 to produce the classification and processing rules. The processing rules 
define how messages are processed. A processing code implements these 
processing rules. The processing code may be, for example, executable 
code or interpretable code, like Java or some scripting language. 

In more detail, the classification of messages is based on some 
20 characteristics of messages, for example, on sender, length, date, time, or 
price information of messages. Also the location of a sender can be a crite- 
rion of the classification. The classification can also be based on the content 
of the message, which can be traced by comparing, for example, matching 
words or bit patterns. The type of the message may as well be one possible 
25 basis for the classification. The message can be plain text, sound, picture, 
data accepted by MMS, some OTA (over-the-air) application or any combina- 
tion of those mentioned. 

The classification affects which processing rules are obeyed, and 
which processing code is run for a message received. For example, the said 

30 message is: 1) rejected or deleted, 2) altered, or 3) directed to other media 
than the original receiver, e.g. an email or a web site or even to another 
SMS-gateway, 4) saved to a database, 5) responded to with certain logic or 
6) left untouched and transmitted to the receiver. It is also possible to store 
only the statistical information about the message or the message may be 

35 stored for a later transmission. 
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The patent application FI20011813 contains profitable solutions for 
classifying messages and handling the said messages according to certain 
processing rules. However, the controlling and managing aspect is poorly 
observed. For example, a common mechanism for controlling the deployment 
5 of a messaging service is missing from the prior art. The deployment in- 
cludes, among other things, the commissioning tests of a messaging service. 
Also a common mechanism for authorizing and supporting the use of mes- 
saging services is still missing from the prior art. 

The main drawbacks of the prior art are listed in the following. 

10 The first drawback is that processes and tools for allowing service 

providers to test and deploy messaging services are incomplete. 

The second drawback is that the billing models and services are 
inflexible for new innovative services. 

The third drawback is a lack of proper business reporting facilities, 
15 which increases business risks. 

The fourth drawback is an inability to sufficiently control different 
type of users and their access to services. 

The fifth drawback is that operators cannot sufficiently control how 
the private user data is provided for service providers. 

20 The sixth drawback is that services often fail to take into account 

different user preferences. 

The seventh drawback is that a user often fails to connect to ser- 
vices because of erroneous terminal configurations. 

25 Summary of the invention 

The objective of the invention is to solve the drawbacks of the prior 
art and define and implement a new type of system for managing messaging 
services. The said system is termed a "messaging manager*. 

The messaging manager has five main tasks: service provider 
30 management, service management, user management, customer care man- 
agement, and managing the quality of service. 
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Service provider management comprises rules and functions, re- 
lated to the service set of a service provider, routing and billing options, and 
limitations which a service operator set for the service set 

Service management comprises the service deployment through a 
5 well-defined process, routing and billing settings, service interfaces, and 
access control. 

User management comprises provisioning of a service through the 
Internet, WAP or short message service (SMS), logins to the service, user 
preferences, and terminal specific settings. 

10 Customer care management comprises means for acting on be- 

half of an end-user. These means are used, for example, when an end-user 
action has failed for some reason. 

Managing the quality of service comprises means for guaranteeing 
a certain quantity of resources for a service. A service provider can choose 

1 5 the level of the quality of service, or the operator may force a certain level. 

These tasks are either performed in the prior art in a service or 
they are not performed at all. In addition, the messaging manager provides 
statistics and reports on e.g. the usage volumes of services. 

The objective of the invention is achieved by locating the messag- 

20 ing manager between the end-users and services, so that end-users' mes- 
sages and services 1 response messages are routed via the messaging man- 
ager. The messaging manager is preferably connected to a message router. 
The most important element of the messaging manager is a profile database 
that contains profiles for service providers, services, end-users, and cus- 

25 tomer care. A profile is a data collection that can be created and updated 
through a user interface, which is most typically a Web interface, and then 
can be stored in the profile database. 

The system is adapted to: 1) receive a message that belongs to a 
communication between an end-user and a messaging sen/ice, 2) obtain 

30 data from the message, and when the obtained data is a search key, 3) 
search at least one profile stored in a profile database by using the search 
key, wherein a profile is a data collection containing information about either 
service providers, services, end-users, or customer care, and when found, 4) 
perform at least one task defined by at least one profile found. When the 

35 obtained data is not a search key, the search key is generated by a certain 
function, which uses the said data as an input. 
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Brief description of the drawings 

The invention is described more closely with reference to the ac- 
companying drawings, in which 

5 Figure 1 shows a message router routing messages between services and 
network operators, 
Figure 2 illustrates the use of a messaging service, 
Figure 3 shows an example of the controlled use of a messaging service 
through the messaging manager, 
10 Figure 4 shows the message manager accessing a profile from a profile 
database and performing a task, 
Figure 5 shows the architecture of the message manager. 

Detailed description of the invention 

15 Messaging manager is a system for managing heterogeneous 

messaging services. The said messaging services may be based on e.g. 
SMS, EMS, MMS, or WAP. The messaging manager enables a service op- 
erator to run messaging services while having full business control over the 
service provisioning and service revenues. Maintaining an evolutionary and 

20 dynamic set of messaging services is a key for maximizing service revenues. 
This sets requirements for a rapid, but controlled, service deployment envi- 
ronment. In order to achieve a win-win situation between a service operator 
and the third party service providers, the messaging services and business 
models should be flexible and easy to understand and implement. The mes- 

25 saging manager provides a service deployment process improving the time- 
to-market of messaging services. 

FIG. 3 shows an example of the controlled use of a messaging 
service through the messaging manager. The messaging service, or briefly, 
the service 301 receives through the messaging manager 304 a user mes- 

30 sage 302 sent by an end-user 303. As response to the message received the 
service 301 sends an output message 305 through the messaging manager 
304 to the end-user 303. The use of the service 301 is controlled in several 
ways. For example, the messaging manager checks whether the user is 
allowed to use the service. In addition, the messaging manager may in 

35 someway change the content of the user message. In this example, the mes- 
saging manager adds a piece of information 306, in more detail, the user's 
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terminal type, to the user message 302. The input message 307 of the ser- 
vice 301 includes the user message 302 and the piece of information 306. 
Therefore the user message 302 is not exactly the same as the input mes- 
sage 307 received by the service 301. Correspondingly, the response mes- 
5 sage 308, which the end-user 303 receives, is not exactly the same message 
305 that the service has sent. The contents of the messages 308 and 305 
are the same, but the message formats are not, which is symbolized with 
lineation. 

Some services are so called push services in which a service just 
10 pushes messages to an end user. A service transaction may be a one-way 
transaction, in which case an end-user does not respond to the messages. 
On the other hand, a push service may initiate a service transaction shown in 
FIG 3. Thus, the service transaction may include transmission of a number of 
messages to many parties. The said messages may be of one or several 
15 message formats, such as SMS or MMS formats. 

A message sent by an end-user is termed "a user message". The 
message that the messaging manager sends to a service is termed "an input 
message". A message sent by the service is termed "an output message", 
and the message that the messaging manager sends to the user is" termed "a 
20 response message". 

The messaging manager may send several output messages per 
one user message and the messaging manager may send several response 
messages per one output message. 

The messaging manager receives user messages and output 
25 messages and creates input messages and response messages. The follow- 
ing list concerns the content and format of these messages: 1) the content of 
a user message may or may not be the same as the content of an input mes- 
sage, 2) a user message may contain more bits than an input message, 3) a 
user message may contain fewer bits than an input message, 4) the format of 
30 a user message may or may not be the same as the format of an input mes- 
sage, 5) the content of a response message may or may not be the same as 
the content of an output message, 6) a response message may contain more 
bits than ah output message, 7) a response message may contain fewer bits 
than an output message, 8) the format of a response message may or may 
35 not be the same as the format of an output message. 
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FIG. 4 shows an example of the message manager accessing a 
profile from a profile database and performing a task. The profiles stored in 
the profile database are a certain type of data collections. When an end-user 
401 wants to use a service 408, he/she sends a message 402 via the mes- 
5 saging manager 403 to the service. The message 402 includes one piece of 
information that is a search key. The message manager obtains the search 
key 404 from the user message and accesses a profile 405 from a profiles 
database 406 by using the search key. After that, the messaging manager 
performs a task defined in the profile accessed 404. According to the task, 
10 the messaging manager sends an input message 407 to the service 408. 

In the above example a message included one search key. How- 
ever, a message may include more than one search key. Each search key is 
one or more pieces of information located in a message. A search key may 
be located in the header of a message or in the data part of the message. 

15 A search key may, for example, be the sender or the receiver of 

the message. Thus, the content of a search key is sometimes the same as in 
the characteristics of a message described in FI20011813. However, a 
search key is certain data that is intended for searching profiles from a profile 
database. The characteristics of a message is not necessary usable for 

20 searching profiles and it is not intended for that. The characteristics of a 
message may affect which method is used to obtain a first search key from 
the message. 

It is also possible that a search key is not explicitly defined in the 
message. Then a certain piece or pieces of information, such as time, date, 
25 operator's name etc., are obtained from the message and used as an input to 
a function, which generates the search key. The information pieces may also 
be read from one or more profiles. The said function is a specific algorithm 
for generating search keys. It may be very simple, so that it just concate- 
nates, for example, the first two and last two bytes of the message. 

30 In the next example the function F obtains the message typei, 

date, and an operator name as input and generates the search key ki : 

k| = F(message typei, date, operator name), 

wherein index i refers to the message typei and a type of the 
search key kj. There could a certain type of the search key k| for different 
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profiles, such as user profiles, service profiles, service provider profiles, etc. 
The message typei of received messages may differ from each other. For 
example, a user message and a service message may be of different types. 

To summarize: there are basically three methods to obtain a 
5 search key. 

The first method is based on reading a predetermined number of 
bytes starting from a certain byte of a message. For example, a search key is 
obtained by reading eight bytes starting from the seventh byte of a message. 

The second method is based on searching a bit or text pattern 
10 from a message, wherein the said pattern determines the location of a search 
key. For example, the text pattern could be "service provider" and the search 
key could be found after this text pattern. 

The third method is based on using a function that obtains one or 
more pieces of information as input and generates a search key. 

15 The type of message may affect which method is used. For exam- 

ple, if the message is a type of extensible mark-up language (XML), the mes- 
saging manager could use the second method to obtain a search key from 
the message. 

A profile is a data collection stored in a profile database. Typically, 
20 the profile database includes various types of profiles, so that there is an own 
profile type for service providers, services, end-users, and customer care. It 
is possible that a database search does not result in any profile. It is also 
possible that a database search results in several profiles, i.e. the search key 
used matches several profiles. For example, a search key could be an 
25 MSISDN of the sender of a message, and the said search key could match to 
one user profile and one service profile. The messaging manager performs 
database searches by using predetermined logic. 

A profile may include one or more search keys referring to other 
profiles, and said profiles may include more search keys. Thus, the profiles 
30 may have one-to-one and one-to-many relationships based on search key 
values. The profiles can be stored in a relation database. The relation data- 
base model is a good choice when each profile includes at least one unique 
search key value. 
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A profile defines at least one task that the messaging manager 
should perform. The tasks could be numbered, for example, so that T 
means "direct a message to a receiver's MSISDN" and '2' means "direct a 
.message to a receiver's email address". Thus, if the profile accessed from 
5 the database includes '2', the messaging manager directs the message to 
the receiver's email address. If required, a task may be a running processing 
code as described in FI20011813. However, the processing code is run only 
if the database search results in a profile that allows the running. 

To- summarize: one message may include one or more search 
10 keys and each search key may match to none or one, or more profiles, and 
each profile may define one or more tasks. 

The messaging manager is adapted to: 

1) receive a message belonging to a communication between an 
end-user and a messaging service, 
15 2) obtain at least one search key from the message, 

3) search at least profile from a profile database by using the 
search key, wherein the profile database contains information about service 
providers, services, end-users, and/or customer care, and when found, 

4) perform at least one task defined by at least one profile found. 
20 The messaging manager is preferably located on top of a messag- 
ing connectivity platform, in more detail, on the top of a message router, such 
as the First Hop message router. 

The messaging manager is equipped with, for example Web- 
based, user interfaces through which users of different user groups can ere- 
25 ate and update their profiles. A user must first authorize himself/herself by 
inputting, for example, a user identifier and a password. After that he/she is 
allowed to handle profiles. The user groups controlled by the messaging 
manager are: service operators, service providers, end-users, and customer 
care personnel. 

30 A service operator can manage its service providers by means of 

the messaging manager. Each service operator is the "superuser" of its own 
system and can override all settings made by e.g. a service provider. 
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Service providers can manage their individual services according 
to permissions granted by service operators. Service providers can assign 
routing and billing rules for services. They can also use interrogation means 
to have reports and statistical information about their services. 

5 . Users can access the messaging manager either by using a Web 

interface, WAP, SMS, MMS, or other messaging technique, and they can 
provide their terminals with correct settings for service accesses, and sub- 
scribe or unsubscribe to services. Users also have access to their prefer- 
ences and service login information. 

10 Customer care personnel can act on behalf of individual end- 

users, for example, by setting terminal configurations or by performing the 
service subscription of an end-user. The customer care personnel are also 
able to offer a message re-sending capability. 

The messaging manager has five main tasks: service provider 
15 management, service management, user management, customer care man- 
agement, and managing the quality of service. These main tasks are dis- 
cussed in more detail. 

Service Provider Management. A service operator registers a 
new service provider by using the messaging manager. In more detail, the 
20 service operator creates a profile for the service provider through the Web- 
based user interface, or another user interface, of the messaging manager. 
The service operator has a profile for each of its service providers. A service 
provider profile includes: a billing model, service usage limitations, service 
deployment rights, routing rules, and/or a choice of MSISDN forwarding. 

25 The billing model sets the billing options for the services of a ser- 

vice provider. A service can set price/tariff information to the messages it 
sends. The messaging manager sets certain limitations defining how the 
service is allowed to set the price/tariff information. Alternatively, a service 
provider obtains a list of price/tariff tags, which the service provider's service 

30 can use in itjs messages and thus demand the messaging manager to set 
certain price/tariff information to the messages. The messaging manager 
controls the use of price/tariff tags. For example, if the service provider tries 
to charge more than it is allowed to, the messaging manager can 1) block the 
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service transaction, 2) block the use of the service, and/or 3) provide a warn- 
ing for the service or service provider. 

Of course, it is also possible that either the message router or the 
messaging manager takes care of the billing process on behalf of a service, 

5 If required, messages can be charged to a service provider. For 

example, a message containing an advertisement could be charged to a 
service provider instead of an end-user. It is also possible to share a charge 
so that an end-user pays a part of the charge and e.g. an advertiser pays the 
rest of the charge. 

1 0 The message router considers the above-mentioned billing options 

when it creates a CDR. The format of the CDR is customizable to match the 
requirements of a billing mediation system. Another billing method than the 
method based on CDRs can be used, too. 

For example, billing capabilities provided by SMS centers can be 
15 used, so that the messaging manager advises the message router to send a 
billing message to the SMSC. The billing message contains the charging 
information in a form that is understandable for the SMS center, and thus the 
SMS center is able to write an appropriate CDR. The end-user may also 
receive the billing message as a receipt of the ended transaction. 

20 A service provider may be given an option to delegate all or some 

subset of its rights to another service provider. This is advantageous, if for 
example, the delegating service provider manages a retail shop chain, and 
the party to which the rights are delegated manages one of the retail shops. 

The service usage limitations are used, for example, to restrict the 
25 number of services that the service provider can deploy. In addition, the 
maximum throughput of a service can be controlled. The throughput is 
measured, for example, as messages per second, or as the number of mes- 
sages 

Service deployment rights concern the deployment of a service. A 
30 right for a SMSC simulator test permits a service provider to deploy a service, 
but only for testing it in the SMSC simulator. End-to-end test right means that 
a service can be deployed for live testing, with a limited number of users. The 
private usage right means that a sen/ice is associated with a whitelist of such 
MSISDNs that are allowed to use the sen/ice. A service provider who has the 
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private usage right can manage its whitelists. Public usage right means that a 
service is public and available to all users not listed in a blacklist. The service 
provider maintains the blacklist associated with the service. A service opera- 
tor may also define that some of its service providers have no service de- 
5 ployment rights. Then the service provider requests the service operator to 
grant a certain right for a certain service. 

Routing rules concern short codes that make the use of a service 
easier. A service operator may assign a number of unique short codes for a 
particular service provider. It is also possible to share a short code between 
10 service providers. Here, the short code is a specific short telephone number 
identified and used by SMS centers to differentiate user-to-service messages 
from user-to-user messages. 

MSISDN forwarding means that a service will receive the MSISDN 
of a sending terminal. Otherwise, a random code will be used instead. 

15 In addition to the options described above, the service operator 

can maintain system wide black- and white lists of users and services. These 
access control lists override .all the other access control definitions made in a 
service level or user level. 

Service Management. As mentioned above, a service operator 
20 creates a profile for its service provider. In this way, the service operator can 
control its service providers. Correspondingly, each service provider man- 
ages its individual services by creating a profile for a service. The service 
provider profile created by the service operator determines which choices 
and settings the service provider is able to make for a service. A service 
25 profile could include, for example: a choice of billing model, an access control 
list, and a choice of a short code. 

In addition, the operator may provide tools for its service provider 
to create other service providers. Typically, these tools are equipped with a 
Web interface through which the service provider can input service provider 
30 specific information, i.e. the service provider can create and update service 
provider profiles and, of course, service profiles. 

The billing model defines how and to whom the use of a certain 
service is billed. The billing model may only be one of those mentioned in the 
service provider profile. 
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Access control is based on a black list or white list. Different lists 
can be used in the different deployment phases mentioned above. 

A short code is used to route messages. The short code may only 
be one of those mentioned in the service provider profile. 

5 A service provider promotes a new sen/ice through predetermined 

deployment phases: 1) SMSC simulator tests, 2) end-to-end tests, and after 
that 3) either private usage or public usage phase. If the SMSC simulator 
tests are successful, the service provider or the service operator grants the 
end-to-end test right for the new service. 

10 The service provider's interface provides an access to statistical 

information concerning the usage of the service provider's services. The 
statistical information may concern, for example, the number of successful 
mobile-originated and mobile-terminated messages for a predetermined 
period of time, or the number of failed messages. The service provider also 

15 has access to the log information of end-users. 

User management. An end-user may access the messaging 
manager by his/her terminal to subscribe or unsubscribe to a service. The 
end-user interface is implemented as a Web interface or via SMS. Through 
these interfaces an end-user can, for example: 1) specify his/her terminal 
20 type, 2) order WAP, GPRS or MMS settings to his/her terminal to be able to 
connect to a service, 3) subscribe/unsubscribe to a service, 4) update his/her 
MSISDN stored in the whitelist of a service, and 5) access the statistical 
information of his/her service usage. 

When an end-user subscribes to a service, the service creates an 
25 end-user profile. The end-user profile includes e.g. an MSISDN, a terminal 
type, and terminal settings. 

The user management can also consider the mutual relationships 
of end-users, such as a breadwinner-child relationship, or an employee- 
employer relationship. Profiles may have a mutual hierarchical relationship, 
30 wherein the said profiles include some identical piece of information. An end- 
user profile, which is on a higher level in the hierarchy, limits or replaces the 
definitions of one or more end-user profiles. 
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For example, a breadwinner's profile may limit which services the 
breadwinner's child can use. Thus, when a message sent by the child is 
received in the messaging manager, the breadwinner's profile is accessed 
from the database and the permission to use a certain service is checked 
5 from the breadwinner's profile. 

Another example concerns an employee-employer relationship 
and sharing messaging charges. An employee and employer have their own 
profiles. Thus, when the employer's message is received in the messaging 
manager, the employer's and the employee's profiles are accessed from the 
10 database. The employer's profile may define some task that the messaging 
manager performs. However, a task related to charging is defined in the 
employee's profile. 

For example, an employer could pay for a service during working 
hours, and outside working hours the employee should pay for the service. A 
15 good example of such a service would be an SMS-based parking payment 
service, i.e. during working hours the employer pays the car parking and 
outside of working hours it is paid by the employee. The decision of how 
much and who is billed is based on available information, such as date, time, 
location information, etc. 

20 Customer care management. The customer care has means for 

acting on behalf of an end-user. Customer care does not need to know the 
password of an end-user to perform the same operation that the end-user is 
able to do. 

If required, customer care can resend a message that an end- 
25 user has earlier tried to send to a service. This message and an associated 
output message of the service are not charged to the end-user. 

A service operator or a service provider can define a profile for its 
own customer care. That customer care profile includes e.g. the employees 
and passwords of the customer care. 

30 Managing the quality of service. The quality of service (Qos) for a 

messaging system is related to several viewpoints. The main viewpoints are: 
1) the throughput defined as messages per a time unit and 2) the maximum 
response delay for a message sent by an end-user. The time unit could be 
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e.g. a second, an hour, or a month. The maximum response delay is often 
inversely proportional to throughput. 

The messaging manager monitors the resource usage of the 
messaging system and allocates the resources to services according to their 
5 quality of service levels. The quality of service (Qos) level indicates the prom- 
ised minimum performance, instead of the maximum performance or average 
performance. The minimum performance is measured as messages per time 
unit or as the number of messages. For example, the minimum performance 
is achieved when a certain service has sent a thousand messages. 

10 Monitoring the resource usage of the whole messaging system and 

its individual services benefits both the service provider and service operator. 
The service provider monitors the resource usage in order to react to the 
following two situations. 

1) When a service has gained popularity among the end-users, it 
15 should be ensured that the said service continually behaves in a satisfactory 

manner. 

2) When the popularity of a service drops and it no longer brings 
revenues to the service provider, the service should either be taken off or 
less money should be spent on its QoS level. 

20 Also the service operator monitors the resource usage of services. 

Then the service operator can purchase, for example, an adequate volume of 
SMSC center connections based on the resource usage and also based on 
the QoS levels. For example, if four services have a QoS level that guaran- 
tees message throughput of 100 messages per second and the maximum 

25 capacity of the messaging system is only 300 messages, a problem occurs if 
the four services simultaneously use their maximum capacity. To solve this 
problem the messaging manager is adapted to continuously 1) calculate the 
resource usage of each service and 2) calculate the sum of the resource 
usage of services. Thus, the messaging manager detects a possible overload 

30 situation. In addition, a Qos level includes a traffic priority. 

The traffic priority has the following impact: if the messaging system 
is overloaded, the services whose QoS includes the highest traffic priority are 
served first. Relating to the above example, the overload is in practice 
avoided by allowing a high traffic priority for three of the four services and a 
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low traffic priority for one of the said services. Then the service having the 
low traffic priority must wait its turn, if the three services use their maximum 
capacity, 100 messages per second. 

The messaging manager is adapted to use two methods for reduc- 
5 ing traffic: 1) delaying the processing of a message until the messaging sys- 
tem is no longer overloaded, or 2) deleting the said message. The choice of a 
method for reducing traffic could be also included in a QoS level. 

The quality of service information may be included in profiles, for 
example, in service provider or service, or user profiles. When the messaging 
10 manager accesses a profile from the profile database, it can obtain the re- 
quired quality of sen/ice information from the profile accessed. 

To summarize: a Qos level includes at least the promised minimum 
performance, which is measured, for example, in messages per second. In 
addition, the QoS level may include the traffic priority and/or the choice of 
15 method for reducing traffic. The messaging manager can control that each 
service obtains the QoS level that the service provider has chosen. 

Architecture of the messaging manager. The messaging man- 
ager and message router are located behind a firewall to eliminate hostile 
accesses to a messaging system 

20 FIG. 5 shows the architecture of the messaging manager. The 

messaging manager 501 contains: the logic for its five main tasks 502-506, 
the profile database 507, the transaction database 508, and the user inter- 
faces 509-512. The user interface 509 of the service provider management is 
intended for a service operator, the user interface 510 of the service man- 

25 agement is intended for service providers, the user interface 51 1 of the user 
management is intended for end-users, and the user interface 512 of the 
customer care management is intended for customer care personnel. 
Through these user interfaces the service operator, service providers, end- 
users, and customer care personnel can access and modify their profiles 

30 stored in the profile database. A message router 513 communicates with an 
end-user 514 and a messaging service 515. The messaging manager 501 
receives messages from end-users and services via the message router 513. 
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A service operator may register a service provider in the service 
operator's messaging system. After registering, the service provider can 
deploy and manage its services. The same applies to end-users, who must 
first authenticate themselves before they are allowed access to their user 
5 profiles. 

Typically, each service provider, service, and end-user has its own 
profile. Customer care may have an individual profile or the customer care 
information may be included in a service operator profile or service provider 
profile. 

10 A service provider can customize the user interface intended for its 

customer care personnel. Furthermore, the service provider may be allowed 
to implement an external user interface for its end-users. 

The messaging manager uses the profile database when one of its 
service providers aims to deploy a service in a server. From the message 
1 5 manager's point of view it is irrelevant who owns the said server or where it is 
located, the messaging manager checks from the service provider's profile 
whether the deployment operation is permissible or not. After a permissible 
service deployment, the messaging manager uses the profile database to 
control the usage of the service. 

20 Profile database is also useful, for example, when a service pro- 

vider wants to customize its service for different types of terminals. 

In another embodiment of the invention the messaging manager 
allows the message router and/or a service to access the profile database. 
Then the message router can perform certain operations. The messaging 
25 manager may allow the service to access the profile database, for example, 
to include service-specific parameters in end-user profiles. 

The messaging manager stores the most recent service transac- 
tions initiated by users or messages in the transaction database. The trans- 
action database can be used for several purposes. 

30 First, the messaging manager may access transaction records 

stored in the transaction database and calculate statistics and form detailed 
business reports for service operators and service providers. 
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Secondly, the messaging manager may use transaction records 
when it guarantees a certain quality of service. In this case, the transaction 
records are counters for counting the resource usage of services. 

Thirdly, the transaction database stores the access history of each 
5 user within a specified time period, thus enabling the customer care person- 
nel to quickly react to an unsuccessful user action. 

The transaction database may be located in a main memory or in 
a disk memory. The same applies to the profile database. 



